Within the general field of SOA, an Enterprise Service Bus (ESB) is used to provide seamless integration between a source service consumer(s) (e.g. client requests) and a target service provider(s) (e.g. answering services). An exemplary ESB that is well-known in the art is capable of handling conversion between different protocols, data transformation and mapping, and translation. An exemplary ESB that is well-known in the art is also capable of routing message exchange between services. The ESB will commonly resolve contention (errors) between communicating services, and control deployment of services.
In a common retail environment, the ESB that is well-known in the art includes at least two features. First, the ESB is capable of sending and receiving electronic messages (e.g., orders, instructions, requests, payments, payment information, and/or other information) to and from one or more source service consumer(s). Some examples of service consumers in an online retail environment include order, payment, inventory, or any business-to-business placement software application. These messages may be in any number of different formats/protocols. Second, the ESB is capable of sending and receiving electronic messages to and from one or more target service provider(s). One example of a target service provider in an online retail environment is an order fulfillment software application.
The ESB may be required to perform a number of complex activities and data/message flow routes. These complex activities and data/message flow routing are based on information/data within each message. Complexity of the system often leads to repetition and redundancies, which in turn lead to reduced efficiencies and increased times for testing and development.
Systems of the prior art inevitably include multiple different software applications that are designed to carry out the same set of instructions and are different only in that each is specifically designed to communicate and interact with a specific format or protocol. In the event that a new software application is introduced into the system employing a new message format or protocol, a whole new ESB solution is required to be designed to address the new format/protocol, even though fundamental purpose and actions remain unchanged.
What is needed in the art is a system and related methods that address these and other shortcomings of the prior art.